- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 19 Sep 2000 14:33:08 -0400
- To: w3c-wai-ua@w3.org
19 September 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Al Gilman
Ian Jacobs (Chair)
Harvey Bingham
David Poehlman
Kitch Barnicle
Tim Lacy
Eric Hansen
Charles McCathieNevile
Absent:
Rich Schwerdtfeger
Gregory Rosmaita
Mickey Quenzer
Regrets:
Jim Allan
Next meetings: 21 September, 26 September
Regrets for 26th: KB, HB, TL for half.
Minutes of previous meeting 14 September:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0387.html
Agenda:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0392.html
Discussion:
1. All Group conference in February 2001. Refer to minute of
chairs meeting (Member only)
http://lists.w3.org/Archives/Member/chairs/2000JulSep/0113.html
JG: How many people would be interested in attending such a
meeting?
Interested an can (hope to) go: HB, KB, AG, DP
Interested but can't go: TL
Action JG: Get back to Chairs and express interest. Suggest that
approximately 10 people would be going.
2.Issue 314: How to distinguish "important elements" (not just type?)
Comments from Al Gilman on 7.6
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0312.html
AG: I think that there are at least three issues:
a) First has to do with the notion of hierarchy and moving through
a hierarchy. I don't think the current 7.6 language gets that
across. It's alluded to in the Guideline prose. One way to
facilitate navigation is to break up chunks of content in smaller
pieces, in multiple phases. I don't think that 7.6 captures this
enough, and it's a piece that is known to be effective (e.g.,
digital talking book model).
b) I have a lot of trouble understanding how you can write a minimal
implementation requirement for navigation and for orientation
independently. Suppose that you filter out some information or
compute a table of contents. If you present that as an auxiliary
table of contents, there are no distinct navigation commands
(beyond switching viewports and following links). This would be
a conforming technique that would require no additional
functionality.
c) The orientation requirement can be slender if the user agent
provides more verbs.
AG: I think the basic profile for hierarchical navigation is next, up,
down relative to some tree. I think "back" is handy as well, but may
not be required for the minimum.
AG: Are the structurally important components of the page going to be
recognizable from the markup of the page? My current assessment of
technology is that they will not. There is no algorithm that will
operate effectively on element types and attributes on its own and
give you an effective navigation tree. I am reluctant to see something
this concrete in the document and it doesn't work. We don't want to
lose our credibility moving forward if it doesn't work.
AG: Hierarchical navigation is desirable, but is not in the current
7.6 language. The problem is that I don't think there's a way to get
there from the markup. I don't think we can claim it's a reasonable
demand on user agents. I don't have an algorithm to give to
developers. Deployed pages won't work. Even following WCAG might not
be sufficient to give clues to authors for using proper markup.
In that document, we don't tell UAs what to look for.
EH: I sympathize with the concern about requiring something where the
markup doesn't adequately support the goal. We also run into this for
equivalents. The markup specified in WCAG 1.0 doesn't fully support
identification of equivalency relationships. However, at a P2 level,
navigating among these elements seems relevant. There are different
models for showing, hiding, and filtering. I want to be convinced that
if we say navigation, that's what we mean, and we need to be sure that
that's what we want (people moving around). If that's what we want, I
don't see this as problematic at a P2 level.
TL: I think it's important that the UAAG 1.0 not require an
algorithm. The trick is obviously to determine the hierarchical
structure. I am not too concerned with a P2 requirement. I'd be
interested in seeing some implementation experience before we attempt
to define more than it is today.
CMN: ISO HTML is defined as having an implicit hierarchical
structure.
AG: In the ISO spec that CMN is referring to, there is a definition
of virtual DIV elements: for every header level there is a presumed
container.
AG: It's beginning to dawn on me that what 7.6 says is that the
list of elements must be reachable. The current 7.6 does not attempt
to provide a top-down breakdown of the document.
IJ: It would be possible to make the list informative and rewrite
the checkpoint more abstractly.
AB: Min requirement is a sliding scale according to how much
navigation or orientation you do.
IJ: It might be possible to push the orientation and navigation
requirements into a single checkpoint.
AG: 7.6 may be ok for what it says, but it doesn't capture the
structural requirement we want in the long term.
EH: Does "semantic" markup include "structural" markup?
IJ: I think this includes semantics defined by specification
as well as metadata.
EH: What about the relationship between semantics and style?
We probably shouldn't think of style as being a proper vehicle
for semantics.
CMN: But unless you allow navigation of it, a heap of what's deployed
will be unreadable. You may not be able to do anything unless you can
navigate according to style.
/* Chair asks if anyone is willing to propose an alternative
checkpoint. */
AG: I think that it's better to make the list informative.
IJ:
- One fear: direct exposure of the tree to users.
- What about changing the wording of 7.6 to be closer
to what AG has said (recursive breakdown of chunks).
AG: I don't want exposure of the full-blown tree, but rather "go to
the next thing like this".
TL: Would it be sufficient to navigate the DOM by adding next sibling?
(next sibling instead of depth-first).
JG: Recall: the DOM walk is not necessarily the best view of the
document. You want less than what's in the DOM.
CMN Proposes:
- Walking a DOM tree up and and down and sibling-to-sibling is one
way to do what we want. However, doesn't really work for HTML 4
(since headings not nested).
- This doesn't solve the table problem.
AG: The solution for the table is that the navigation grid is not a
tree within the table. It's an array.
TL: We work on table navigation a lot. Complex when you have
nested tables.
IJ: I think we decided a long time ago that table navigation would
not be a focus of this document. Please do not open that discussion
right now...
AG: I'd like to create an abstraction of the DOM tree and providing
motion in that tree that includes breadth-first navigation.
CMN: We don't have any other motion requirements. I think that not
being able to page backwards is a serious flaw and if I didn't have
it, I would throw my UA away.
AG: Eyes-free user is more dependent on indexed access.
CMN: I think forward navigation of the tree alone is not
enough. If you have to go back to the start of the tree each time, you
are throwing away context each time. This requires you to remember too
much. I would require up, down, left, right in the tree. The DOM tree
is one such tree. The implicit ISO HTML tree is another.
EH: For documents written in a book style (with nested subheads),
implicit DIVs are a useful technique. But there are a lot of Web pages
not constructed that way.
/* We note that WCAG talks about this without referring to ISO HTML:
"3.5 Use header elements to convey document structure and
use them according to specification. [Priority 2]"
*/
EH: If we are assuming WCAG 1.0 conformance, we can write checkpoints
that assume this usage.
IJ Summarizing:
1) Make list of elements informative
2) Reword requirement based on top-down breakdown.
3) Movement requirement: top/down/left/right
4) Different DOMs are useful
Action CMN: Propose a new structured navigation checkpoint.
Deadline for discussion next Tuesday.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Tuesday, 19 September 2000 14:33:09 UTC